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(54) Handling connections moving between firewalls 



(57) A method of handling mobile entities in a fire- 
wall, wherein a first mobile entity table comprising iden- 
tifiers of mobile entities, which are active in a firewall, 
and a second mobile entity table comprising identifiers 
of mobile entities, which are active in a predefined set 
of other firewalls and identifiers of corresponding other 
firewalls, are maintained (400, 402) in the firewall. A new 
mobile entity, which is not currently active in the firewall, 



is detected (404), after which it is found on the basis of 
the second mobile entity table, if the new mobile entity 
is currently active in another firewall. If the mobile entity 
is currently active in another firewall, state information 
related to the new mobile entity is queried (408) from 
the another firewall, and stored (410) in the firewall to 
be used for processing data packets from/to the new 
mobile entity. 
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Description 



Field of the Invention 



[0001] The present invention relates to network secu- 
rity and, more particularly, to firewalls or security gate- 
ways. 

Background of the Invention 

[0002] Typically, various organizations protect their 
internal networks by means of a firewall, which connects 
the internal network of the organization to public net- 
works and filters and selectively discards the data pack- 
ets entering and exiting the internal network according 
to predefined rules. Thus, a firewall is a gateway which 
operates at the same time as a connector and a sepa- 
rator between the networks in a sense that the firewall 
keeps track of the traffic that passes through it from one 
network to another and restricts connections and pack- 
ets that are defined as unwanted by the administrator of 
the system. Physically a firewall is a machine with ap- 
propriate software to do the tasks assigned to it. It can 
be a router, a personal computer (PC), or whatever that 
can be used for such purposes. 

[0003] Frequently, the filtering rules of a firewall are 
expressed as a table or list (rule base) of rules compris- 
ing data packet characteristics and related actions. Data 
packet characteristics are parameter values that are ob- 
tained from header field of a data packet and may be e. 
g. source IP (Internet Protocol) address, destination IP 
address and service (or protocol) or some other values. 
The action gives information about how to handle a data 
packet, which corresponds the data packet characteris- 
tics defined in the respective rule (i.e. which matches 
the rule). This means that for a data packet, which has 
the header information indicated in a rule, the action in- 
dicated in the rule is carried out. In a firewall, the action 
is typically deny or allow, which means the data packet 
is discarded or allowed to proceed, correspondingly. 
[0004] The rules of a rule base are examined in cer- 
tain order until a decision how to process the data packet 
is reached. The order of the rules in the rule base typi- 
cally defines the order in which characteristics of a data 
packet are compared to the rules, that is, the rules are 
examined one by one from the beginning of the rule 
base. When a rule, to which the characteristics of a data 
packet match, is found, the action that is related to that 
rule is taken and often there is no need to continue ex- 
amining the rules. However, the action defined in the 
rule may be continue, in which case examining the rule 
base is continued from the next rule, or jump, in which 
case examining the rule base is continued from the rule 
specified in the jump action. The action of the firewall 
may be as well reject, which is similar to deny action. 
The difference is that deny action results in simply dis- 
carding the data packet and in reject the sender of the 
data packet is notified of discarding the data packet. 



[0005] Figure 1 illustrates as an example a rule base 
10, having * rules. In each rule, a rule number, source 
IP address fSC ADDR, destination IP address DST AD- 
DR, service or protocol) and action are defined. How- 
5 ever, this is only an example structure of rules, and also 
some other data packet characteristics may be defined 
in the rules. The rule#1 allows HTTP (Hyper-Text Trans- 
fer Protocol) data from any address to a server with IP 
address 172.16.1.10. All other HTTP traffic is denied 
to with rule #2. That is, if HTTP traffic does not match the 
rule #1, it is denied. Rules #3 and #4 allow FTP (File 
Transfer Protocol) traffic from network 10.1 .1 .0 to FTP 
server at IP address 192.168.1 .15 and Telnet connec- 
tions from network 10.1.1 .10 to any address, respecti ve- 
ts iy. The firewall rule bases are commonly designed to 
prohibit all that is not expressly permitted in the rules. 
Therefore, the last rule in the rule base is usually de- 
signed to deny any data packet. Rule #5 in the rule base 
10 is such rule, that is, it denies data packets of related 
20 to any service from any source address to any destina- 
tion address. So, if a data packet does not match any of 
the firstf our rules, it matches this last one and is denied. 
[0006] In summary, when a data packet is received in 
the firewall, some of the header field values of the data 
25 packet are compared to the rules, which are stored in 
the firewall, and when a matching rule is found, the ac- 
tion related to the matching rule is taken. 
[0007] In a stateful firewall, information aboutconnec- 
tion history is maintained. In general, a data packet 
30 opening a connection is compared to the rules in the 
rule base, and if the data packet is allowed, a state is 
created for the opened connection. The state is created 
by making into a connection state table an entry includ- 
ing information for identifying the connection (e.g. 
35 source and destination address, ports and/or protocol) 
and the state of the connection . Other than data packets 
opening a connection are then compared to the connec- 
tion state table and allowed, if a corresponding entry is 
found and the data packet is in accordance with the state 
40 of the connection. At the same time the state of the con- 
nection in the connection state table may be updated. If 
a corresponding entry is not found in the state table, the 
data packet may be compared to the rules in the rule 
base and possibly allowed on the basis of rules or simply 
45 discarded. Stateful inspection makes processing of data 
packets belonging to open connections faster than sim- 
ple packet filtering on the basis of rules. Additionally, 
state of the connections (the data packets that have al- 
ready been allowed and possibly their content) can be 
so taken into account in processing data packets, which 
makes stateful firewall more secure than simple packet 
filter. Therefore stateful processing is desirable. 
[0008] Traditionally, IP (Internet Protocol) address of 
an entity uniquely identifies the entity's point of attach- 
55 ment to the Internet. Therefore, the entity must be locat- 
ed on the network indicated by its IP address in order to 
communicate using the IP address. Otherwise, the data 
packets destined to the entity by using its IP address 
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would not be deliverable. Mobile IP (Internet Protocol) 
is a protocol for enabling an entity to change its point of 
attachment to the Internet without changing the IP ad- 
dress it is using. That is, an entity can use the same IP 
address even if its location in the network changes. 5 
From the network point of view, this means that the path 
used to deliver the traffic for the entity can change. 
[0009] According to mobile IP, each mobile node (or 
entity) is always identified by its home IP address, re- 
gardless of its current point of attachment to the Internet. io 
When the mobile node (MN) is outside its home network 
and therefore not directly reachable by its home IP ad- 
dress, a care-of address, which provides information 
about its current point of attachment to the Internet, is 
assigned the mobile node in addition to the home IP ad- 15 
dress. The care-of address may be the IP address of a 
foreign agent (FA) located in the network the mobile 
node is visiting or it may be a co-located care-of ad- 
dress, which is an address of the network the mobile 
node is visiting, which is dynamically assigned to the 
mobile node (e.g. by means of DHCP, Dynamic Host 
Configuration Protocol). The mobile node registers the 
care-of address with a home agent (HA) in its home net- 
work by sending a Registration Request message (UDP, 
User Datagram Protocol, data packet to port 434) to 
which the home agent responds with a Registration Re- 
ply message in IPv4, which is the "current" version of 
Internet Protocol. In IPv6, which is the next generation 
of Internet Protocol, the registration is done by means 
of specific Extension Headers, wherein Binding Update 
and Binding Acknowledgement Destination Options 
(corresponding to Registration Request and Registra- 
tion Reply respectively) are transmitted. 
[0010] When the mobile node is in its home network, 
it communicates with other entities by using its home IP 
address normally. When the mobile node is outside its 
home network that is, in a foreign network, other entities 
still reach the mobile node by using its home IP address. 
After the home agent has been notified that the mobile 
node is in a foreign network with a Registration Request 
message / Binding Update Destination Option giving the 
mobile nodes current care-of address, the home agent 
intercepts the data packets destined to the mobile 
node's home IP address. The home agent then encap- 
sulates these data packets to data packets destined to 
the mobile node's care-of address (tunnels data pack- 
ets) for delivery to the mobile node. If the care-of ad- 
dress is the address of the foreign agent, the foreign 
agent is the endpoint of the tunnel and it decapsulates 
the data packet and delivers the original data packet to 
the mobile node. Similarly, if the care-of address is a co- 
located care-of address, the mobile node is the endpoint 
ofthetunnelandit decapsulates the data packet for ob- 
taining the original data packet. The mobile node sends 
reply packets directly to the other end. In IPv6, the mo- 
bile node sends reply packets by using its care-of ad- 
dress as source address, and attaches its home ad- 
dress to a Home Address Extension Header. In this way 



the data packets are routed correctly (correct source ad- 
dress) and the other end is able to identify the mobile 
node by extracting the static home address form the 
Home Address Extension Header. After this the other 
end may communicate directly with the mobile node; 
this is done by using the care-of address of the mobile 
node as a destination address, but including also mobile 
node's home address in data packets in a Routing Ex- 
tension Header. 

[0011] The methods of mobile IP are deployed also in 
General Packet Radio Service (GPRS). GPRS Tun- 
neling Protocol (GTP) is the protocol used between 
GPRS Support Nodes (GSNs) in the UMTS/GPRS 
backbone network. It includes both the GTP signaling 
(GTP-C) and data transfer (GTP-U) procedures. In 
GPRS, special support nodes called Gateway GPRS 
Support Nodes (GGSN) and Gateway Serving GPRS 
Support Nodes (SGSN) are deployed. SGSNs provide 
the direct access point for GPRS phones, subtending 
from GGSNs that provide the gateway to SGSNs across 
mobile networks that the user may visit. The GGSN also 
is the access point for other packet data networks, such 
as Internet, and therefore enables communication be- 
tween "normal" IP networks and GPRS devices. GTP is 
used to forward packets from GGSN to SGSN to reach 
a mobile device, dynamically setting up tunnels between 
GGSN and its home network and allowing the mobile 
unit to have its home network served beyond the GGSN 
Internet Gateway. GTP allows the GPRS user to be 
reachable from data networks, such as Internet, by us- 
ing the same addressing information irrespective of its 
point of attachment to the network. 
[0012] It is common that there is one firewall protect- 
ing the home network of a mobile node, and another fire- 
wall protecting a foreign network the mobile node is vis- 
iting. These networks may for example subnetworks be- 
longing to the same organisation. Statefull filtering in a 
firewall uses information about previous packets of a 
connection for processing other data packets of the con- 
nection. In a situation, where statefull firewall starts see- 
ing traffic in the middle of a connection it lacks the nec- 
essary information for processing the data packets and 
therefore discards the data packets and the respective 
connection fails. This happens when a mobile node 
moves from one network to another without changing 
the addressing information it is using. Therefore, infor- 
mation about the state of the connections needs to be 
shared between firewalls in order to enable connection 
roaming from one firewall to another. 
[0013] In clustered firewalls (multiple parallel fire- 
walls) and high availability solutions the state informa- 
tion is shared between firewalls (synchronization of 
state information) in order to enable one firewall to con- 
tinue processing of a connection previously processed 
by another firewall. In these solutions, the state of each 
connection currently processed in each relevant firewall 
is usually synchronized to all other firewalls. This is fea- 
sible in a clustered firewall, since any of the cluster 
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members need to be ready for taking over the connec- 
tions processed by some other cluster member, and the 
number of the cluster members is in practice limited to 
a reasonable number. However, synchronizing all avail- 
able state information between firewalls does not suit 
well for handling the location changes of mobile IP us- 
ers. The distance between firewalls sets some limita- 
tions to the amount of information that is feasible to be 
shared. Additionally, synchronizing all state information 
would result in sharing unnecessary information as well, 
since many of the connections handled by the firewalls 
are from static sources and only some may involve a 
mobile user. 

[0014] Due to these deficiencies, a more suitable 
method for enabling connection roaming between fire- 
walls is needed. 

Summary of the Invention 



[0015] An object of the invention is to fulfill the need 
described above by providing a method for handling mo- 
bile entities in firewalls and maintaining information in 
firewalls. 

[0016] The objects of the invention are achieved ac- 
cording to the invention as disclosed in the attached in- 
dependent claims. Preferred embodiments of the inven- 
tion are disclosed in the dependent claims. The features 
described in one dependent claim may be further com- 
bined with features described in another dependent 
claim to produce further embodiments of the invention. 
[0017] The idea of the invention is to synchronize high 
level information about active mobile entities between 
firewalls, and when a mobile entity moves from a first 
firewall to a second one, to fetch the accurate state in- 
formation related to the mobile entity from the first one 
to the second one to be used in the second one for han- 
dling the connections of the mobile entity. Where to fetch 
the information is known on the basis of the synchro- 
nized high level information. Information about all active 
entities in a f irewall do not need to be synchronized, but 
only information about active mobile entities, which may 
be reached by static addressing information irrespective 
of their point of attachment to the network. For such mo- 
bile entities, the open connections should not fail due to 
change of location. Information about which IP address 
may be used by mobile entities or which iP addresses 
may not be used by mobile entities may be configured 
in the firewalls in order to identify mobile entities. In prac- 
tice, the firewalls among which the information is shared 
are firewall of one organization, e.g. firewall of one com- 
pany or firewalls of an operator offering connectivity 
services to a plurality of customers. It is also possible 
that all connections, which are conveyed inside a tunnel 
(that is encapsulated into another data packet), are con- 
sidered as connections, which are potentially used by 
mobile entities. Therefore, information about the end- 
points of such tunnelled connections may be synchro- 
nized by the method according to the invention. Also de- 



tecting an IPv6 Extension Header (e.g. Home Address 
Header or Routing Header) can be used for identifying 
connections of potentially mobile entities. 
[0018] According to the invention a first mobile entity 
5 table comprising identifiers of mobile entities, which are 
active in a firewall, and a second mobile entity table 
comprising identif iers of mobile entities, which are active 
in a predefined set of other firewalls and identifiers of 
corresponding firewalls, are maintained in the firewall. 
10 An identifier of a mobile entity may be for example an 
IP address or a subscriber n umber. Especially if the con- 
nections of the mobile entity are transferred within a tun- 
nel, the identifier may be other than an IP address. 
When a new mobile entity not currently active in the fire- 
15 wall is detected, it is found on the basis of the second 
mobile entity table, if the new mobile entity is currently 
active in another firewall, and if the mobile entity is cur- 
rently active in an other firewall, state information related 
to the new mobile entity is queried from the another fire- 
20 wall, and the received state information is stored in the 
firewall to be used for processing data packets from/to 
the new mobile entity. 

[0019] Detecting a new mobile entity may involve de- 
tecting a data packet in which the source is the new mo- 
25 bile entity or detecting registration of the new mobile en- 
tity. The registration may be detected due to negotiation 
for a new location or detecting routing protocol traffic. 
For example, the Session Initiation Protocol (SIP) may 
indicate that a mobile entity is moving from one firewall's 
30 influence to another's. A new entry corresponding to the 
new mobile entity is added in the first mobile entity table 
after detecting the new mobile entity. 
[0020] The state information related to the mobile en- 
tity is history information of the open connections of the 
35 mobile entity, which is used in stateful connection 
processing in a firewall. The state information may in- 
clude also authentication information or some other in- 
formation used in processing data packets associated 
to the entity in question. 
40 [0021 ] A firewall according to the invention sends the 
first mobile entity table to a predefined set of other fire- 
walls as a response to a predefined action, such as an 
indication of a certain time period having elapsed since 
the first mobile entity table was sent the last time, a 
45 change in the content of the first mobile entity table, or 
receiving a request for the first mobile entity table. 
[0022] The firewall receives from at least one other 
firewall a mobile entity table comprising identifiers of 
mobile entities which are active in the at least one other 
so firewall. On the basis of the received mobile entity table 
the firewall updates (deletes, adds or modifies entries) 
its second mobile entity table and deletes an entry in its 
first mobile entity table, if a corresponding entry is con- 
tained in the received mobile entity table. Receiving an 
55 entry of the first mobile entity table in a mobile entity 
table of some other firewall indicates that the corre- 
sponding entity has moved from the firewall to the other 
firewall and may therefore be deleted from the first mo- 
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bile entity table of the firewall as unnecessary. The state 
information associated with the mobile entity are in prac- 
tice queried from the firewall by the other firewall before 
deleting the corresponding entry in the first mobile entity 
table of the firewall. Alternatively, entries of a first mobile 
entity table may be removed also on the basis of a timer. 
[0023] The invention relates as well to a method of 
maintaining information in a firewall, comprising main- 
taining a first mobile entity table comprising identifiers 
of mobile entities which are active in the firewall, sending 
the first mobile entity table to a predefined set of other 
firewalls as a response to a predefined action, receiving 
from at least one other firewall a mobile entity table com- 
prising identifiers of mobile entities which are active in 
the at least one other firewall, and maintaining a second 
mobile entity table comprising identifiers of mobile enti- 
ties which are active in the at least one other firewall and 
an identifier of the corresponding firewall on the basis 
of the mobile entity table received from at least one other 
firewall. 

[0024] A firewall according to invention may request 
from at least one other firewall a mobile entity table com- 
prising identifiers of mobile entities which are active in 
the at least one other firewall for maintaining the first 
mobile entity table in the firewall. 
[0025] Compared to traditional synchronization of 
state information used e.g. in clusters, the method ac- 
cording to the invention requires much less information 
transfer between the firewalls. 

[0026] These and other features of the invention, as 
well as the advantages offered thereby, are described 
hereinafter with reference to embodiments illustrated in 
the accompanying drawings. 

Brief description of the drawings 

[0027] 

Figure 1 illustrates an exemplary prior art rule base, 
Figures 2A, 2B and 3 are schematic block diagrams 
of exemplary network configurations wherein the 
present invention can be applied, 
Figure 4A is a flow diagram illustrating operation ac- 
cording to one aspect of the invention, 
Figure 4B is a flow diagram illustrating detection of 
a new mobile entity according to the invention, 
Figure 5 is a flow diagram illustrating exemplary 
methods for triggering sending a mobile entity table 
to other firewalls, and 

Figure 6 is a flow diagram illustrating an exemplary 
method for handling a received mobile entity table. 

Preferred embodiments of the invention 

[0028] The present invention can be applied in any 
stateful network gateway or firewall, which is processing 
data packets of mobile entities, which may be reached 
by static addressing information irrespective of their 



8 

point of attachment to the network. For such mobile en- 
tities, the open connections should not fail due to 
change of location. 

[0029] The data connectivity of the mobile entity may 
5 be through wireless or fixed line connection. Typically 
such mobile entities are portable computer devices, 
such as laptop computers, PDAs, communicators, 
smart phones, intelligent telecommunication devices, 
etc. The physical location independence of the mobile 
10 entities may be based on mobile IP GTP or some other 
protocol. The system providing connectivity to the mo- 
bile entity may be but is not limited to LAN (Local Area 
Network), WLAN (Wireless LAN), GSM (Global System 
for Mobile communications), GPRS (General Packet 
15 Radio Service), or UMTS (Universal Mobile Telecom- 
munications System). 

[0030] The invention relates to synchronizing high 
level information about active mobile entities between 
firewalls, and when a mobile entity moves from a first 
20 firewall to a second one, to fetching the accurate state 
information related to the mobile entity from the first one 
to the second one to be used in the second one for han- 
dling the connections of the mobile entity. Whereto fetch 
the information is known on the basis of the synchro- 
's nized high level information. 

[0031] Figures 2A, 2B and 3 are schematic block di- 
agrams of exemplary network configurations wherein 
the present invention can be applied. The configurations 
are shown only to facilitate the understanding and de- 
30 scription of the present invention. The present invention 
is not intended to be restricted to any particular network 
configuration. Further, in order to improve clarity, mainly 
only network elements which are somehow involved 
with the present invention are shown in Figures 2A, 2B 
35 and 3. 

[0032] Figure 2A shows a network configuration in 
connection with mobile IP. A subnetwork 200 is connect- 
ed to a public network 203 via a firewall system 205. The 
firewall system contains three parallel firewalls 206, 207 

40 and 208 in order to ensure connectivity through the fire- 
wall system. However, in the connection of this invention 
the structure of the firewall system is not relevant. An- 
other subnetwork 202 is connected to the public network 
via a firewall 204. A mobile node 201 is connected to 

45 the subnetwork 200, which is its home network. A home 
agent 21 0 is as well connected to the subnetwork 200. 
The mobile node communicates with a correspondent 
node 209 attached to the public network 203. With help 
of the home agent 21 0, the mobile node may change its 

50 point of attachment to the subnetwork 202 (shown with 
dashed line in Figure 2A) without breaking its connec- 
tion with the correspondent node 209. In this case, the 
connection is first handled with the firewall system 205 
and then with the firewall 204. Assuming that the fire- 

55 walls are stateful firewalls and in order not to break the 
connection state information needs to be shared be- 
tween the firewalls 204 and 205. Using the method ac- 
cording to the invention in the firewalls enables this. 
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However, if the mobile node 201 has ongoing connec- 
tions within the subnetwork 200 before the change of 
the location, those connections fail after the move, since 
the firewall system 205 does not have information about 
the connections inside the subnetwork 200. 
[0033] Figure 2B shows another network configura- 
tion in connection with mobile IP. Three subnetworks 
231 , 232 and 233 are connected to an internal network 
230 via firewalls 236 (a cluster containing two parallel 
firewall devices 236 and 237) , 239 and 240. The internal 
network 230 is connected to public network 203 via a 
firewall 235. A mobile node 234 is connected to the sub- 
network 231 and may change its location to any of the 
subnetworks 232 and 233 (shown with dashed line in 
Figure 2B) : therefore the firewalls 236, 239 and 240 
need to be able to handle moving open connections. 
The physical location of the mobile node 234 is known 
to a home agent 242 in the internal network. The mobile 
node may communicate for example with a correspond- 
ent node 241 connected to the public network 203. 
[0034] Figure 3 illustrates a schematic block diagram 
of exemplary network configuration related to GPRS 
system where the invention may be used. Therein two 
wireless subnetworks 302 and 31 8 are connected to a 
service network 308 via SGSNs 304, 320 and GGSNs 
306, 322. SGSNs provide the direct access point for 
GPRS devices in the subnetworks 302, 318. GGSNs 
that provide the gateway to SGSNs across mobile net- 
works that the user may visit. The GGSN also is the ac- 
cess point for other packet data networks, such as In- 
ternet, and therefore enabling communication between 
"normal" IP networks and GPRS devices. Data is trans- 
ferred between SGSNs and GGSNs in tunnels accord- 
ing to GTP (GPRS Tunneling Protocol). Between the 
SGSN 304 and GGSN 306 there is afirewall 305 filtering 
the GTP tunnel. Accordingly, there is a firewall 321 be- 
tween the SGSN 320 and the GGSN 322. The service 
network 308 is further connected to a public network 31 4 
(such as Internet) via a gateway 31 2, which may or may 
not be a firewall device. 

[0035] In subnetwork 302 there is connected a GPRS 
device 300, which may communicate with an entity 31 0 
connected to the service network 308 or with an entity 
316 connected to the public network 314. These con- 
nections go through the firewall 305. The GPRS device 
300 may change its location to the subnetwork 318 
(shown with dashed line in Figure 3), which causes that 
the connections of the GPRS device move to the firewall 
321. 

[0036] Naturally, the coupling between the different 
networks in Figures 2A, 2B and 3 may include also rout- 
ers and Internet service providers (not shown in Fig- 
ures). As is well known in the art, the internal networks 
or subnetworks may be, for example, company net- 
works, such as a local area networks (LAN) or a wireless 
LANs (WLAN) which connect users and resources, such 
as workstations, servers, printers and the like of the 
company. Alternatively, the internal networks or subnet- 



works may consist of connections of individual subscrib- 
ers such as ADSL subscribers or subscribers of a wire- 
less network such as GSM, GPRS or UMTS network. In 
this case, the term internal network may not be very de- 
5 scriptive, and instead a term such as a service network 
could be used. 

[0037] The method of the invention may be used for 
example in any of the firewalls 204, 205, 236, 239, 240, 
305, 321 discussed above. As already described above, 
w the firewalls 204, 205, 236, 239, 240, 305, 321 are gate- 
ways which operate at the same time as connectors and 
separators between the networks in a sense that the 
firewalls keep track of the traffic that passes through 
them from one network to another and restrict connec- 
ts tions and packets that are defined as unwanted by the 
administrators of the systems. Physically a firewall is a 
device with appropriate software to do the tasks as- 
signed to it. It can be a router, a personal computer (PC), 
or whatever that can be used for such purposes. 
20 [0038] Figure 4A is a flow diagram illustrating opera- 
tion according to one aspect of the invention. In steps 
400 and 402, a first mobile entity table comprising iden- 
tifiers of mobile entities, which are active in a firewall, 
and a second mobile entity table comprising identifiers 
25 of mobile entities, which are active in a predefined set 
of other firewalls and identifiers of corresponding fire- 
walls, are maintained in the firewall. An identifier of a 
mobile entity may be for example an IP address or a 
subscriber number. Especially if the connections of the 
30 mobile entity are transferred within a tunnel, the identi- 
fier may be otherthan an IP address. In step 404, a new 
mobile entity not currently active in the firewall is detect- 
ed. Then, it is found on the basis of the second mobile 
entity table, if the new mobile entity is currently active in 
35 another firewall (step 406) . If the mobile entity is current- 
ly active in another firewall, state information related to 
the new mobile entity is queried in step 408 from the 
another firewall, and the received state information is 
stored in the firewall to be used for processing data 
40 packets from/to the new mobile entity in step 410. Instep 
41 2, a new entry corresponding to the new mobile entity 
is added in the first mobile entity table. If it is found in 
step 406 that the mobile entity is currently not active in 
any other firewall, the process proceeds straight to step 
45 412 for adding a new entry. In this case, it is assumed 
that the mobile entity is only starting communication and 
does not have any ongoing connections open. 
[0039] The state information related to the mobile en- 
tity is history information of the open connections of the 
50 mobile entity, which is used in stateful connection 
processing in a firewall. The state information may in- 
clude also authentication information or some other in- 
formation used in processing data packets associated 
to the entity in question. 
55 [0040] Figure 4B is a flow diagram illustrating detec- 
tion of a new mobile entity according to the invention. 
Detecting a new mobile entity may involve detecting a 
data packet in which the source is the new mobile entity 
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in step 414 or detecting registration of the new mobile 
entity in step 41 6. The registration may be detected due 
to negotiation tor a new location or detecting routing pro- 
tocol traffic. For example, the Session Initiation Protocol 
(SIP) may indicate that a mobile entity is moving from 
one firewall's influence to another's. SIP is an Internet 
Engineering Task Force (IETF) standard protocol for in- 
itiating an interactive user session that involves multi- 
media elements such as video, voice, chat, gaming, and 
virtual reality. Because the SIP supports name mapping 
and redirection services, it makes it possible for users 
to initiate and receive communications and services 
from any location, and for networks to identify the users 
where ever they are. In relation to Mobile IP, the change 
of location may be detected from Registration Request 
/ Binding Update messages. 

[0041] A firewall according to the invention sends the 
first mobile entity table to a predefined set of other fire- 
walls as a response to a predefined action. Figure 5 is 
a flow diagram illustrating exemplary methods for trig- 
gering sending a mobile entity table to other firewalls. In 
step 500 it is checked, if a predefined time period has 
elapsed since the first mobile entity table was sent the 
last time. If it has, the first mobile entity table is sent in 
step 502 to a predefined set of other firewalls. In step 
504 it is checked, if the content of the first mobile entity 
table has changed. If it has, the first mobile entity table 
is sent in step 502 to a predefined set of other firewalls. 
This may be done also so that when ever an entry is 
added, deleted or modified in the first mobile entity table, 
it is sent to the other firewalls. In step 506 it is checked, 
if a request for the first mobile entity table is received. If 
it is, the first mobile entity table is sent in step 502 to a 
predefined set of other firewalls. 
[0042] The other firewalls to which the table is sent 
are typically firewalls of one organization, e.g. of one 
network operator administering the services offered to 
the customers by means of firewalls, which allow only 
the type of connections forthe customers they have sub- 
scribed for. 

[0043] Figure 6 is a flow diagram illustrating an exem- 
plary method for handling a received mobile entity table. 
In step 600, a firewall receives from at least one other 
firewall a mobile entity table comprising identifiers of 
mobile entities which are active in the at least one other 
firewall. In step 602 : the second mobile entity table in 
the firewall is updated on the basis of the received mo- 
bile entity table. Updating involves deleting, adding and/ 
or modifying entries. In step 604 it is checked if one of 
the entries in the firewall's first mobile entity table is in- 
cluded in the received mobile entity table. If that is the 
case, the corresponding entry is deleted in the firewall's 
first mobile entity table in step 606. If there are no entries 
of the first mobile entity in the received mobile entity ta- 
ble, only the second mobile entity table needs to be up- 
dated. 

[0044] Receiving an entry of the first mobile entity ta- 
ble in a mobile entity table of some other firewall indi- 



cates that the corresponding entity has moved from the 
firewall to the other firewall and may therefore be delet- 
ed from the first mobile entity table of the firewall as un- 
necessary. The state information associated with the 

5 mobile entity are in practice queried from the firewall by 
the other firewall before deleting the corresponding en- 
try in the first mobile entity table of the firewall. Alterna- 
tively, entries of a first mobile entity table may be re- 
moved also on the basis of a timer. 

w [0045] It must be appreciated that the embodiments 
described above are given as examples only, while the 
features described in one example may be combined 
with features of another example and various modifica- 
tions can be made within the scope and spirit of the in- 

15 vention as defined in the appended claims. 



Claims 

20 1. a method of handling mobile entities in a firewall, 
characterized in 

maintaining (400) a first mobile entity table 
comprising identifiers of mobile entities which are 
active in the firewall, 

25 maintaining (402) a second mobile entity table 

comprising identifiers of mobile entities which are 
active in a predefined set of other firewal Is and 
identifiers of corresponding other firewalls, 

detecting (404) a new mobile entity, which is 

30 not currently active in the firewall, 

finding (406) on the basis of the second mo- 
bile entity table, if the new mobile entity is currently 
active in another firewall, and 

if the mobile entity is currently active in anoth- 

35 erfirewall, querying (408), from the another firewall, 
state information related to the new mobile entity, 
and storing (41 0) the state information in the firewall 
to be used for processing data packets from/to the 
new mobile entity. 

40 

2. A method according to claim 1 , further character- 
ized in 

adding (412) a new entry in the first mobile 
entity table after detecting a new mobile entity not 
45 currently active in the firewall, the new entry corre- 
sponding to the new mobile entity. 

3. A method according to any one of preceding claims, 
further characterized in 

50 sending (502) the first mobile entity table to a 

predefined set of other firewalls as a response to a 
predefined action. 

4. A method according to claim 3, characterized in 
55 that the predefined action is an indication of certain 

time period having elapsed (500) since the first mo- 
bile entity table was sent the last time. 
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5. A method according to claim 3, characterized in 
that the predefined action is changing (504) the 
content of the first mobile entity table. 

6. A method according to claim 3, characterized in 
that the predefined action is receiving (506) a re- 
quest for the first mobile entity table. 

7. A method according to any one of preceding claims, 
further characterized in 

receiving (600) from at least one other firewall 
a mobile entity table comprising identifiers of mobile 
entities which are active in the at least one other 
firewall, 

updating (602) the second mobile entity table 
on the basis of the received mobile entity table, and 

deleting (606) an entry in the first mobile entity 
table, if a corresponding entry is contained in the 
received mobile entity table. 

8. A method according to any one of preceding claims, 
characterized in that detecting a new mobile entity 
comprises 

detecting (414) a data packet in which the 
source is the new mobile entity. 

9. A method according to any one of claims 1 to 8, 
characterized in that detecting a new mobile entity 
comprises 

detecting (416) a registration message from 
the new mobile entity. 

10. A method according to any one of preceding claims, 
characterized in that the identifier is an IP address 
or a subscriber number. 

11. A method according to any one of preceding claims, 
characterized in that the state information related 
to the new mobile entity comprises state of the on- 
going connections of the new mobile entity. 



12. A method of maintaining information in a firewall, 
characterized in 

maintaining (400) a first mobile entity table 
comprising identifiers of mobile entities which are 
active in the firewall, 

sending (502) the first mobile entity table to a 
predefined set of other firewalls as a response to a 
predefined action, 

receiving (600) from at least one other firewall 
a mobile entity table comprising identifiers of mobile 
entities which are active in the at least one other 
firewall, and 

maintaining (402) a second mobile entity table 
comprising identifiers of mobile entities which are 
active in the at least one other firewall and an iden- 
tifier of the corresponding at least one other firewall 
on the basis of the mobile entity table received from 



said at least one other firewall. 

13. A method according to claim 12, further character- 
ized in 

5 requesting from the at least one other firewall 

a mobile entity table comprising identifiers of mobile 
entities which are active in the at least one other 
firewall. 

10 14. A method according to any one of claims 12 to 13, 
characterized in that the predefined action is an 
indication of certain time period having elapsed 
(500) since the first mobile entity table was sent the 
last time. 

15 

15. A method according to any one of claims 12 to 13, 
characterized in that the predefined action is 
changing (504) the content of the first mobile entity 
table. 

20 

16. A method according to any one of claims 12 to 13, 
characterized in that the predefined action is re- 
ceiving (506) a request for the first mobile entity ta- 
ble. 

25 

17. A firewall (204, 205, 236, 239, 240, 305, 321) char- 
acterized in comprising 

memory and mechanism for maintaining a 
first mobile entity table comprising identifiers of mo- 
30 bile entities which are active in the firewall, 

memory and mechanism maintaining a sec- 
ond mobile entity table comprising identifiers of mo- 
bile entities which are active in a predefined set of 
other firewalls and identifiers of corresponding oth- 
35 er firewalls, 

mechanism for detecting a new mobile entity, 
which is not currently active in the firewall, 

mechanism for finding on the basis of the sec- 
ond mobile entity table, if the new mobile entity is 
40 currently active in another firewall, and 

mechanism for querying, from the another 
firewall, state information related to the new mobile 
entity, and mechanism and memory for storing the 
state information in the firewall to be used for 
45 processing data packets from/to the new mobile en- 
tity, if the mobile entity is currently active in another 
firewall. 



18. A firewall (204, 205, 236, 239, 240, 305, 321 ) char- 
50 acterized in comprising 

memory and mechanism for maintaining a 
first mobile entity table comprising identifiers of mo- 
bile entities which are active in the firewall, 

mechanism for sending the first mobile entity 
55 table to a predefined set of other firewalls as a re- 
sponse to a predefined action, 

mechanism for receiving from at least one 
other firewall a mobile entity table comprising iden- 
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tifiers of mobile entities which are active in the at 
least one other firewall, and 

memory and mechanism for maintaining a 
second mobile entity table comprising identifiers of 
mobile entities which are active in the at least one 
other firewall and an identifier of the corresponding 
at least one other firewall on the basis of the mobile 
entity table received from the at least one other fire- 
wall. 



w 



19. A computer-readable medium, characterized in 

containing a computer software which, when exe- 
cuted in a computer device, causes the computer 
device to provide a firewall routine comprising 

maintaining afirst mobile entity table compris- 15 
ing identifiers of mobile entities which are active in 
the firewall, 

maintaining a second mobile entity table com- 
prising identifiers of mobile entities which are active 
in a predefined set of other firewalls and identifiers 20 
of corresponding other firewalls, 

detecting a new mobile entity, which is not cur- 
rently active in the firewall, 

finding on the basis of the second mobile en- 
tity table, if the new mobile entity is currently active 25 
in another firewall, and 

if the mobile entity is currently active in anoth- 
er firewall, querying, from the another firewall, state 
information related to the new mobile entity, and 
storing the state information in the firewall to be 30 
used for processing data packets from/to the new 
mobile entity. 

20. A computer- read able medium, characterized in 

containing a computer software which, when exe- 35 
cuted in a computer device, causes the computer 
device to provide a firewall routine comprising 

maintaining a first mobile entity table compris- 
ing identifiers of mobile entities which are active in 
the firewall, 40 

sending the first mobile entity table to a pre- 
defined set of otherf irewalls as a response to a pre- 
defined action, 

receiving from at least one other firewall a mo- 
bile entity table comprising identifiers of mobile en- 45 
tities which are active in the at least one other fire- 
wall, and 

maintaining a second mobile entity table com- 
prising identifiers of mobile entities which are active 
in the at least one other firewall and an identifier of so 
the corresponding at least one other firewall on the 
basis of the mobile entity table received from the at 
least one other firewall. 

21. A computer program comprising program code 55 
means for performing all the steps of any of claims 

1 to 1 6 when the program is run on a computer. 
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